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SUMMARY 



A team comprised of personnel from AFHRL, McDonnell Douglas Astronautics Company, Denver 
Research Institute, and Softech determined requirements for and developed the Instructional 
Support System (ISS). The basis for this development was the Advanced Instructional System 
(AIS), a computer-based Instructional system developed jointly by AFHRL and McDonnell Douglas 
Astronautics Company. 

E*rly in the project, McDonnell Douglai teamed with Denver Research Institute to determine 
the functional requirements of the ISS. An examination of key DOD training systems occurred to 
determine the feasibility of adding certain key features to the ISS at reasonable cost. Also, 
several kty DOD training environments were examined to determine training requirements the ISS 
would need to address. Existing AIS capabilities as well as Inputs from these DOD analyses were 
used to create a Functional Description of the ISS. Existing AIS software which best satisfied 
the Functional Description were then converted. 

Nine basic applications software modules, comprising approximately 300,000 lines of source 
code, exist as a result of the conversion. They are CAI Authoring, CAI Presentation, Graphics, 
Simulation Authoring, Simulation Presentation, CMI Development, CMI Operation, Data Analysis, and 
Access/Security. 

A translator was developed by McDonnell Douglas and Softech to assist In the conversion from 
CAMIL (Computer-Assisted/Managed Instructional Language), the primary language of Implementation 
for the AIS, to Ada, the primary language of Implementation for the ISS. The translator was 
capable of translating approximately 80% of a CAMIL program to correct Ada. Approximately 20* of 
a CAMIL program was either partially translated or untranslated. These areas were clearly marked 
with manual translation hints In the resultant Ada. 

The ISS Application Support Environment (ASE) was developed concurrently with conversion of 
the applications software. The purpose of the ASE Is twofold: First, It provides portability to 
the ISS, given that machine and operating system dependencies are Implemented at the lowest level 
of the support envVonment; second, It provides a variety of basic runtime support services to 
ISS applications software to assist In the areas of user Interaction, data processing, and 
storage and retrieval of data. 

Finally, an Important aspect In the success of the Standardized Software project was a 
microcomputer analysis, conducted to analyze and recoranend small machines capable of executing 
ISS software modules. An MC68000 basic Pacific Microcomputer PM200 was procured by the Air Force 
as a result of the study. Key software modules were successfully compiled and executed on the 
system, demonstrating the concept of ISS transportability and feasibility of running the ISS on a 
microcomputer. 
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PREFACE 



A nwrter of Individuals have contributed significantly In the successful design and 
1*>le*entat1on of the ISS. Alphabetically, these Individuals are: Dick B0I2 
(AFHRL/XD), Dave Grossart (MDAC), Alan Hallauer (MDAC), Alan Marshall (AFWL/ID), Glenn 
McBrlde (MDAC). Anne Montgomery (MDAC), Dave Pflasterer (MDAC). Steve Schaefer (MDAC) , 
Rick Shelgren (MDAC), Mark Weinberg (MOAC), and Dana Wunderllch (MDAC). 
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INSTRUCTIONAL SUPPORT SOFTWARE SYSTEM 



1.0 INTRODUCTION 

The prototype Advanced Initructlonal System (AIS) was designed as a research and development 
test bed for technical training. As such. It demonstrated that Individualized computer-assisted 
Instruction (CAI) and computer-managed Instruction (CMI) are directly applicable to an 
operational Air Force training environment. 

Although demonstrated as feasible, the original system was not transportable; therefore, 
exploitation of the training technology was limited. In order to correct this problem, the 
Technical Training Division of the Air Force Human Resources Laboratory (AFHRL) awarded a 
contract to the McDonnell Douglas Astronautics Company to create a tr reportable system. This 
Standardized Software project had as the major goal to create a transportable instructional 
system that 1s implementable on low-cost minicomputers and microcomputers In order to expand Into 
thv appropriate DOD training environments. The transportable system, called the Instructional 
Support Software (ISS) system, has been developed and alpha tested. An operational test of the 
system Is projected to begin during tne third quarter of 1985. 

The Air Force set forth several key requirements to accomplish Us major goal. It was 
decided that Ada, the newly standardized DOD language, would be used to enhance system 
portability. Ada Is the ideal language In which to Implement transportable software, given Us 
mission as a standard high-order language that will become available on many machines. 

Another requirement was to develop a set of generalized interfaces to enhance portability. 
By embedding macnlne dependencies low into the ISS support software, the necessary interface to 
the host operating system could be accomplished 1n a portable way. 

The final key requirement was to create application software made up of modular components to 
support the execution of Individual portions of the ISS. Components such as Authoring, Graphics, 
and CAI Presentation were to be created for execution on an Individual basis. By allowing 
potential DOD customers the capability to choose only a subset of the entire ISS, particular 
needs can be met at lower cost. 

In order to report the significance and results of the Standardized Software project, the 
following sections of this report will provide a project description, a statement of the major 
accomplishments of the project, Information on ISS potential, and conclusions and recommendations. 



2.0 PROJECT DESCRIPTION 

Early in the project, McDonnell Douglas teamed with the Denver Research Institute to 
determine the functional requirements of the ISS. Key DOO training systems were examined to 
determine the feasibility of adding certain key features to the ISS at reasonable cost. Also, 
several key DOD training environments were examined to determine what training requirements the 
ISS would need to address. Existing AIS capabilities, as well as Inputs from these DOO analyses, 
were used to create a functional description of the ISS. Existing AIS software which best 
satisfied the functional description was then converted. 

Nine basic application software modules, comprising approximately 300,000 lines of source 
code, exist as a result of the conversion. They are CAI Authoring, CAI Presentation, Graphics, 
Simulation Authoring, Simulation Presentation, CMI Development, CMI Operation, Data Analysis, and 
Access/Security. 
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A translator was eloped to assist In the conversion from CAMIL (Computer-Assisted/Managed 
Instructional Language), the primary language of Implementation for the AIS, to Ada, the primary 
language of implementation for the ISS. The translator was capable of translating approximately 
80X of a CAMIL program to correct Ada. Approximately 20% of a CAMIL program was either partially 
translated or untranslated. These areas were clearly marked with manual translation hints In the 
resultant Ada. 

The ISS Application Support Environment (ASE) was developed concurrently with conversion of 
the application software. The purpose of the ASE is twofold. First, it provides portability to 
the ISS, given that machine and operating system dependencies are implemented at the lowest level 
of the support environment. Second, it provides a variety of basic runxlme support services to 
ISS application software to assist in the areas of user Interaction, data processing, and storage 
and retrieval of data. 

Finally, an Important aspect In the success of the Standardized Software project was a 
microcomputer analysis, conducted to analyze and recommend small machines capable of executing 
ISS software modules. An MC68Q00-based Pacific Microcomputer PM200 was procured by the Air Force 
as a result of the study. K«*y software modules were successfully compiled and executed on the 
system, demonstrating the concept of ISS transportability and the feasibility of running the ISS 
on a microcomputer. 



3.0 MAJOR ACCOMPLISHMENTS 

The goals set forth at the beginning of the Standardized Software project have been 
accomplished. Applications software which best satisfies the functional description has been 
converted or developed. The developed system Is portable. After the software had first been 
produced on the development machine (VAX-11/780) and then transported to the PM200 microcomputer, 
the concept of portability had been demonstrated. And finally, the system has been Implemented 
on a low-cost minicomputer and microcomputer. 

The ISS is organized using a layered shell approach to allow for maximum ease of maintenance 
and transportability. The design philosophy of the software is depicted in Figure 1. ISS users 
Interface with a set of programs called the Applications Software (described In Section 3.1). 
The next layer of software, called the Application Support Environment, performs the interfacing 
tasks necessary to support the Applications Software. The Innermost layer Is the Operating 
System Software. This software provides Interface to the computer hardware. The advantage of 
this layered approach Is that changes in basic hardware configuration or operating system 
software are unlikely lo adversely affect the ISS Applications Software. The Applications 
Software Is buffered by a layer of support environment software that performs the Interfacing 
between Applications Software and the operating system and hardware. 

The following sections discuss In more detail the major accomplishments during the project. 

3.1 Converted Applications Software 

With the ISS software modules, a user is able to develop, implement, and evaluate training. 
Table-driven database programs, called editors, are dominant in the system, thereby allowing a 
user to easily Insert, display, and/or change information in the database. The most Important 
characteristic of the editors Is that they allow quick access to the database via menus and 
prompts. No computer programming skills are necessary for ISS system users. 
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Figure 1. ISS Software Structure, 

The applications sof^are Is divided Into two major functions: the CAI system and the CMI 
system. The former provides the development and delivery capability for on-line CAI t while the 
CMI system controls the administrative and management functions for a given Installation. Both 
systems are Integrated Into the ISS package and share a common base of data and utility programs. 

The CAI system allows nonprogrammers to develop and evaluate Individualized, Interactive CAI 
modules containing a variety of text and graphics. Using the CAI editors, development of 
courseware takes the form of an ongoing dialog between the author and the system. There are 
three major authoring programs In the CAI software: CASS, SID, and GraphEdlt. CASS Is the 
screen-frame-or1ented t courseware-authoring editor that guides the author via the use of menus. 
SID Is an action-to-screen-oriented simulation courseware authoring editor that also guides the 
author via menus, GraphEdlt Is a graphics creation editor for CASS and SID that guides the 
graphics artist through Input from mary possible sources such as the keyboard, a digitizer 
tablet, a touch panel, a Joy-disk, or a light pen. Like the other editors, GraphEdlt Is 
menu-driven. 

CAI lessons are delivered to students through CAI software modules: CAI Presentation 
(CAIPres) and Simulation Presentation (SIDPres), These modules provide the student wltft all CAI 
and simulation lessons and allow for Interaction, screen (tynamlcs, branching, remediation, 
feedback, and prompts. Like the authoring modules, CAIPres and SIDPres are menu-driven and 
user-friendly. 

The M system provides comprehensive management Information and aAnlnlstratlon 
Implementation. It controls the scheduling of assignments, testing, remediation, and enrichment 
activities for each student. 
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Four major editors assist the curriculum developer In describing the curriculum By uslno 
these four editors, the Curriculum Definition Editor (CDE), the Course St uc e Ed 1 tor (S 
the Lesson Definition Editor (LDE), and the Test Editor (TESTED), curriculum developer d 

"s7^e^ f1 "j n c c ;r: ,n91y ti detaned °< * ««: ^keus 

tasic is complete, the CMI operation programs administer the curriculum. 

sel/lT re9fSt ; a < t1 < 0n ' C0UrSC StruCture ^nagement, resource management, and student 
self-pacing are maintained by th.ee CMI programs comprising the CHI operations module The 
programs are Student Logon, Student Registration, and the Adaptive Model. 

three'cm^luJtlir'? 31 ,tU * n \ 0vera11 course P"»™» monitored and recorded by 

Ev Nation slarv r/ S ? 9 T S .T r1 V nS ! thC A " a1ySlS "° dule - ^ ™ r ™ •« Course 

Eva uatlon Summary ( ES), Test Item Evaluation (TIE), and t s Lata Extraction Program (DEP). 

These programs report data such as the standard deviation/mean times and test scores for 

™mii£z?TiZ?S£; (cesk detennine standard f0 

curr ill, ! ♦« 1 K 3nd SCleCt iny available data « ad h°', to run analysis for 

curriculum evaluation and student/group performance (DEP). ono.yiii ror 

The Access/Security module is used to define the access a user will have to the ISS The 
Access/Security software Is necessary to allow operation of all of the other ISS software Th! 
software contains two programs: L'SRED and LOGON. software. The 

that" 561 " 5 , °! 3 COn,pUter - based trafnf "9 svs ^ are typically concerned with the security measures 
that control access to the system. USRED allows system managers to control access To aT ss 

ZZV nd S °H? are ' " 1dCntff1eS USerS> databaSC V"!™' and courses to the ISS system 
and authorizes and/or restricts the access of Individual users to ISS editors, database programs 
and courses. USRED can also regulate a user's level of access within a spec 1c TtZle 
program or course. One may, for example, give a user permission to add and/or c 
informa Ion in a specific course, but not to delete Information. One may give another e 
permission to display Information but not to manipulate It in any way. 

chec^ntT "Tl Pr ° VldeS 311 USCrS Wfth 3CCeSS t0 the ISS - lt als ° felons « a security 
checkpoint by requiring the user to enter a specific ID followed by a specific password L^GON 
c mpares the Information entered by the user with Information that has bee stored by USRED 
the user record. If no match Is found. LOGON Instructs the user to reenter the data. 

Students entering LOGON are automatically transferred to the Student Logon program Once in 
Student Logon, a student user can interact with the ISS fo, training activities. 

list of editors and database programs that have been authorized the user via USRED. 



3.2 CAHIL-to-Ada Translator 



t« al^TT h r bee " dGVel0ped t0 assfst 1n the conversion from CAMIL (AIS-3.8-1674, 1979) 
a Imumi ™ TJ\ C nT ° f tranSlat1n9 a PP^l m ately 80. of a CAMIL program to correct 
Ada ANSI/MIL-STD-1815A, 1933). Approximately 20% of a CAMIL program is either partlallv 

r^ n I I t1n 0 ni:sTn Sl t a h ted - ^Z"'"/ " UntranSlatCd are m£?«l m 

tra slation hints in the resultant Ada. Figure 2 illustrates the mechanism used to translate a 
CAMIL program to Ada and to compile and link that Ada program into executable form. 
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Figure 2. Automatic Translation from CAMIL to Ada. 

The functional units that comprise the translator are generally the same as those that 
comprise the CAMIL ccnpller. The major differences In the translator functional units are as 
follows: (See Figure Z and DD1017F019, 1974.) 

1. Modification of production action routines. 

2. Replacement of code generation routines with Ada source generation routines, 

3. Additions to data structures for symbol and type table entries. 

Other minor differences exist. For example, the translator version of the lexical analyzer 
and parser saves Information abcut comments appearing In the source so that they may be preserveo 
In the Ada translation, figure 3 Illustrates the combined top-level functional decomposition of 
the CAMIL compiler and the translator. Note that the portion labeled Code Generator Is pa*t of 
the CAMIL compiler and Is replaced by the Translation Routines and Ada Source Generator In the 
translator. All the other top-level functional units are shared by botn tne compiler and the 
translator (with the differences aheady mentioned). Sections 3.2.1 and 3.2,2 contain a general 
description of how a translation Is accomplished. 



3.2.1 Translator Action Routines 

Each time the translator's parser recognizes a particular construct or portion of a construct 
(called production) In the CAMIL language, It Invokes an associated action routine. These action 
routines are responsible for checking semantic restrictions and building data structures (called 
semantic frames) to represent the con^ruct recognized. Syntax checking Is done by the parser. 

The semantic frames generated by action routines are placed on a stack which Is pushed and 
popped by the parser as constructs are recognized. In this way, an action routine for a 
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Figure 3. Tranalator Functional Decomposition. 

low-level productlo- (for example, one that processes an operator expression) can pass 
Information about . t production to another action routine associated with a higher level 
production (for example, an assignment statement production In which the operator expression 
forms the right-hand side). 

The action routines representing the declaration productions (e.g., variable declarations) 
build symbol and type table entries using information that has been .aved m semantic frames by 
action routines. 

Similarly, action routines Invoked for statement level productions (e.g., assignment) call 
translation routines to generate code passing them Information saved In ;emant1c frames (e.g., 
variable and expression frames) built by lower frames (on the parser stack), which represent the 
parts of the right-hand side of the semantic production. The action routine usually generates a 
new semantic frame that Is Input to higher level productions; however, some action routines 
generate a symbol or type table entry and/or call a translation routln* to generate Ada source 
code. 



3.2.2 Translation Routines 

The translation routines are organized in a manner that roughly parallels the productions. 
These routlnws are Initially invoked by statement level action routines and Internally Invoke 
each other to complete translation of « statement. The transition routines call the routines 1n 
the Ada source generator that actually generate the source string. The translation routines 
operate by "walking" through the semantic tree and calling Ada source generation routines. 
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3.3 Tht Application Support Envlronmtnt 



The purpose of the Application Support Environment 1s twofold* First, 1t provides 
portability to the ISS, given that machine and operating system dependencies are Implemented at 
the lowest level of the support environment* (S"e Section 3*4.) Second, 1t provides a variety 
of basic runtime support services to ISS applications software to assist in the areas of user 
Interaction, data processing, and storage and retrieval of data, 

The Application Support Environment 1s divided Into two layers: the Application Support Layer 
(ASL) and the Virtual Machine Layer ( VML). Figure 4 illustrates the division of the Application 
Support Environment 1n order to support t > applications software and to interface to the host 
operating system. This section of the report describes the support services provided -by the ASL 
to the applications software. The VML is discussed in Section 3,4, The ASL provides software in 
the areas of terminal communications, data management. Inter-process communication, text 
handling, program control, and mathematical services. 
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Figure 4. ISS Software Structure Illustrating the Divided 
Application Support Environment. 

3.3.1 Terminal Communication 

The Terminal Communication component provides the functional Interface between the ISS 
applications software and the terminal devices used to communicate with applications software 
users. Terminal devices can be easily added since individual terminal characteristics are stored 
1n data tables. All that 1s necessary for the ISS to support a new terminal type is to enter the 
data describing the new terminal Into the terminal definition table. The full set of combined 



text/graphics display characteristics and capabilities provided by the Terminal Conrounication 
component are as follows: 



1. Characters per line range from 60 to 128. 

2. Lines per screen rarge from 24 to 64. 

3. Lines are numbered from 1 to L with line 1 at the top of the screen and line L at the 
bottom of the screen. 

4. Columns are numbered from 1 to C with column 1 at the leftmost character cell position 
and column C at the rightmost position. 

5. Random cursor positioning Is possible to any character position within the character 
matrix defining the screen. 

6. Random cursor positioning to any dot position within the dot matrix Is possible. 

7. Double he<ght and width characters, as well as normal height and width characters, are 
display able. 

8. Lines of dots from the current dot position to a different dot position are displayable. 

9. Either a complete or partial circle of dots with a given radius Is display able, starting 
at the current cursor position. 

10. Text and graphics are dlsplayable In eight different colors. 

11. It Is possible to select whether background or foreground elements can blink. 

The terminal keyboard Is toe means by which users of an application program Input data to 
that program. Keypresses are Interpreted by the Terminal Communication component and acted upon 
where appropriate. Provisions are made for four distinct types of keys. These keys, as well as 
the set of keyboard characteristics and capability, are as follows: 

1. Textual Data Keys - This set of keys represents the printable character symbols as 
defined In the ASCII character set. 

2. Function Keys - This set of keys has special meaning to the Terminal Communication 
component. Entry of an enabled function key triggers a preemptive transfer of control from the 
current point of execution within an application program to a handler area previously declared 
within the program. 

3. Action Keys - This set of keys has special meaning to the Terminal Communication 
component. Entry of an action key causes the Terminal Communication component to act on the data 
being assembled by a keyboard read operation (e.g., deletion of a character by pressing the 
delete key). 

4. Terminal Control Keys - This set of keys has special meaning to the Terminal 
Communication component. Each terminal control key represents a special terminal control 
function which can be performed by pressing that key. The terminal control functions generally 
affect the current display screen attributes (e.g., color and blink). 
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3.3*2 Data Management 



The Data Management component consists of the ISS database and the necessary operations 
required by the applications software for accessing and maintaining the database. The database 
Is the data storage system for all of the data objects used by the ISS applications software. It 
supports Indexed Sequential, Direct Access, and Sequential files. The names of the files are 
stored In a directory within the database along with sufficient additional information necessary 
to access the file. A file cannot span disks but Is otherwise not limited in size. The 
characteristics of the different file types are as follows: 

1. Indexed Sequential (ISAM) Files - An ISAM file Is capable of containing zero or more 
records, each of which may contain a variable amount of data. For each ISAM file In the data 
base, a "key" Is defined which designates that a specific portion of each record be used to 
define j sequential ordering of the records contained in that file. Each record is at least long 
enough to contain the entire key. An Inaex sufficient to map key values to record locations, In 
order to support random record accessing, is maintained for each ISAM file. An ISAM key can be a 
maximum of 127 bytes. 

2. Direct Access (DA) Files - A DA file Is capable of containing zero or more records, each 
of which may contain a variable amount of data. Each record within a DA file Is associated with 
a relative record number which defines the sequential ordering of the records contained in that 
file. An Index sufficient to map relative record numbers to record locations, In order to 
support random record accessing, Js maintained for each Direct Access file. The maximum relative 
record number in use for each file Is maintained In order to facilitate the allocation of unused 
relative record numbers to new records entered Into that file. 

3. Sequential Files - A sequential file Is capable of containing zero or more records, each 
of which contains a variable amount of data. The records within a sequential file have a 
sequential ordering based on the order that the records were written Into the file. 



3.3.3 Inter-Process Co— unlcatlon 

The Inter-Process Communication component provides a set of functional capabilities to 
applications software to enable concurrently active ISS processes to communicate among 
themselves. Figure 5 depicts that communication. The process Is the logical unit of activity 
within the ISS execution environment and the primary entity relating to Inter-Process 
Communication. It Is an active computing environment that can support the sequential execution 
of one or mere programs. Each active ISS user Is associated with a dedicated process and 
Interacts with ISS application programs that execute within this dedicated process. The 
operating system used by ISS systems and applications software supports the execution of multiple 
concurrent processes; therefore, multiple, concurrent ISS users are supported. 

Each active ISS process Is associated with a system-wide ISS Process Index Number which 
uniquely Identifies that process within the system. The Process Index Number Is kept across the 
execution of multiple ISS application programs. At the completion of an ISS process, the Process 
Index Number Is deallocated, allowing other processes to reuse the number. 



3.3.4 Text Handling 

The Text Handling component provides a set of functional capabilities to ISS applications 
software to manipulate text for display, comparison, assignment, examination, and conversion 
to/from non-textual data types. Two data types comprise textual data In the ISS: String and 
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Figure 5. Inter-Process Co«min1cat1on. 

Character. String and Character data contain one or more characters of ASCII encoded data 
representing dlsplayable characters or control characters. String data may also contain generic 
codes that specify functions to be accomplished by the Terminal Communication component. 

A string has an actual length and a maximum length associated with it. A variable string has 
a termination character to indicate the actual length, with the maximum length Indicated at the 
time of declaration. For the string declaration 

S : STRING (1..5); 

the maximum length 1s 5. By Initializing "S" with the assign string procedure 
ASST(S, "ABC"); 

the actual length 1s set at 3. "S M would appear as M ABCtc M In computer memory, where tc fs the 
termination character. If the actual length of a variable string Is equal to the maximum length, 
then no termination character 1s stored In the string. The actual length Is determined to be the 
maximum length when the appropriate string-handling procedures detect no termination character. 



3.3.5 Progrm Control 

The Program Control componer* provides services to assist In the control of the execution 
flow of ISS programs. The design of existing software for the ISS assumes some additional 
execution control flow capabilities beyond those available in the ISS Implementation language, 
Ada. The services provided by Program Control are as follows: 
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1. Program Transfer - An ISS program is able to designate which program should execute 
within the Current process after the current program terminates its execution. 

2. Inter-Program Data Passage - An ISS program is capable of passing data for retrieval by 
the next program specified for execution. 

3. Timed Walt - The capability exists for a program to suspend us execution for a 
designated time Interval; the granularity of time is .01 second. 

4. Obtaining Date and Time of Day Information - The capability exists for obtaining the 
current date (year, month, day, and Julian date) and current time (hour, minute, and second). 

5. Obtaining elapsed and central processing unit (CPU) Time - Tne capability exists for 
obtaining the elapsed and CPU time for a session. The variables returned are in 10-mlllisecond 
units. 



3.3.6 Mathematical Services 

The Mathematical Services component provides a set of capabllltes to ISS applications 
software to perform trigonometric, boolean, exponentiation, logarithmic, and other miscellaneous 
mathematical functions. 

Three types comprise the data that can be manipulated by the mathematical functions: 
INTEGER, FLOAT, and BOOLEAN. The INTEGER and FLOAT data types are Implementation defined with 
respect to magnitude. If a particular host supports 32-bit integers, for example, an ISS INTEGER 
will be 32 bits. If a host supports 16-bit Integers, an ISS INTEGER will be 16 bits. The 
BOOLEAN data type is represented as an enumeration type in the following way: 

type boolean Is (false, true); 



3.4 Software Portability 

In completing the design and Implementation of a transportable system, it has been determined 
what capabilities are necessary in candidate systems in order to port the ISS to those systems 
(Marshall, 1983). Requirements of a candidate system can be divided into (a) Ada programing 
language requirements, (b) host operating system requirements, and (c) hardware requirements 
(processor/peripherals and terminal). A discussion of those requirements follows in the next 
three sections of this report, followed by a section describing experience transporting the ISS 
from the development machine (VAX-11/780) to the PM200 microcomputer. 



3.4.1 Ada Programming Language Requirements 

Since the ISS is implemented in the Ada language, it will be necessary for any candidata 
system to provide an Ada compiler. Using such a system does not guarantee successful 
Implementation of the ISS, however. For example, some existing validated compilers Impose 
limitations with respect to code/data sizes and pragma Implementation (a pragma conveys 
information to the compiler but does not affect the correctness of a program). Also, some 
existing compilers are Incomplete Implementations and do not provide features neeae* by the ISS. 

If code and/or data are limited to 32k or 64k in a particular implementation of Ada, some ISS 
programs will not execute without modification on that system. 
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Certain pragmas are necessary for a production Implementation of the ISS (or a means must be 
devised to equivalents Implement the effect of missing pragmas). If the pragma PACK does not 
sufficiently pack data, data management performance will degrade because records will be much 
larger than If packing were available. If the pragma INTERFACE 1s not pro/1ded by an Ada 
compiler, It 1s awkward to Interface to the ISS VML procedures (Figure 4) that are necessary to 
Implement the ISS. If the pragma SUPPRESS Is not available, costly execution time checks on 
subranged Integer assignments and array bounds will constantly occur, causing a degradation 1n 
performance due to high CPU utilization. Also, while the pragma INLINE Is not required, its 
presence Is beneficial since sound design principles can then be used. By appropriately using 
procedures and functions and declaring them to be compiled Inline, performance 1s not degraded 
due to costly procedure call and function call linkage. 

Note that In certain cases 1t may be possible to Implement a system without the pragma PACK, 
pragma INTERFACE, and pragma SUPPRESS. Alternate methods causing the same effect should always 
be considered. 

3.4.2 Host Operating System Requirements 

In order to fulfill ISS functionality and performance needs, ASL software must utilize VML 
machine-dependent procedures (Figure 4). These VML procedjres, written In a non-Ada language 
provided by the host system, must be relmplemented on a system to rehost the ISS to that system. 
The VML procedures are of two different forms; (a) procedures that call host operating system 
software to gain needed functionality, and (b) procedures that have been written to attain 
necessary performance. (These procedures are Invoked with high frequency but do not use 
operating system functions; since they are In a machine-dependent, non-Ada language, It can be 
said that they comprise a portion of host operating system requirements.) In an attempt to 
minimize tk size of the VML, the number of procedures has been kept as small as possible. 
Tables 1 and 2 describe procedures that are of each form. To clearly depict what host operating 
system software the ISS requires, the tables specify the VML entry point names and the 
functionality requirements fulfilled (Table 1) or the performance requirements fulfilled (Table 
2). Note that It may be possible to Implement some of the VML procedures In Ada on some systems 
and still meet the functionality and performance requirements. Therefore, 1n evaluating any 
future candidate system, a rigid examination should not occur for operating system capabilities 
that match exactly the requirements given 1n Tables 1 and 2. Where appropriate, equivalent and 
acceptable Implementations for fulfilling requirements should be considered. 



3.4.3 Hardware Requirements 

Computer hardware Is available 1n a wide range of varying capacity, functionality, and 
performance. This section of the report describes the basic requirements of a hardware system 
capable of developing and executing the ISS. 

It Is not necessary to require processor, storage, and display station equipment to be 
packaged either together 1n a desktop unit or separately 1n order to successfully develop and 
execute the ISS on that equipment. For clarity, however, processor/peripheral requirements are 
described separately from display station requirements. 
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TableJ_. VML Proctdures Utilizing Host Operating Systen Software 



VNL Entry Point Name 



Functionality Requirement Fulfilled 



1 . BACKSPC 

2. CALL 

3. CHI LDACTI V£ 

4. CLOSET 

5. DISMOUNT 
6* EXP 

7. FCLOSE 

8. F CREATE 

9. FGETS 
10* FOP EN 
11. FPUTS 
12* FREAD 

13. FREEMEM 

14. FREMOVE 

15. FSEEK 

16. FWRITE 

17. GETT 

18. GETJ)ATETIME 

19. GETJTRMJNFO 

20. GET_TID 

21 . GETJIMERS 

22. GET_PID 

23. IBOOL 

24. INTOCHAR 

25. LOW_LOCK 

26. LOWJJNLOCK 

27. MOUNTT 
26. NEWMEM 

29. OPENT 

30. PGMJXISTS 

31 . PUTT 

32. PRINTFILE 

33. RAND 

34. RESUMEPROCESS 

35. REWINOT 

36. RUNPGM 

37. RUNPROGRAM 

38. SHIFT 

39. STOPPROCESS 

40. SMMITFILE 

41. SUSPENOPROCESS 

42. TEMPFILE 

43. TRANLOG 

44. TRAPMACHINEEXCEPTIONS 

45. TRIG 

46. UNIT_READ 

47. UNITJvRITE 

48. WAIT 



Back space 1 record on a tape file 
Call procedure with absolute address 
Check for an active sub-process 
Close a tape file 
Dismount a tape 

Raise e to power of input value 
Close a file 
Create a database file 
Read a system file record 
Open a database file 
Write a system fll« record 
Read a database record 
Deallocates dynamic storage 
Remove a file 

Position to a database record 

Write a database record 

Read a tape record 

Return the current date and time 

Return input terminal type 

Return the tt-mlnal Identification 

Return elapsed and CPU time 

Return the process Id 

Perform specified boolean oper. 

Convert an 1ntc;:r to a character 

Lock a resource 

Unlock a resource 

Mount a tape 

Allocate dynamic storage 
Open a tape file 
Determine If a program exists 
Put a tape record 
Print a file 

Generate a random number 

Resume a process 

Rewind a tape file 

Run a non-background program 

Run a background program 

Perform specified shifting oper. 

Stop a process 

Submit a command file 

Suspend a process 

Create a name for a system file 

Translate logical to actual name 

Set up to trap machine exceptions 

Perform the specified trig funct. 

Read Input from a terminal 

Write output to a terminal 

Halt program for Input time 
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Table 2. VML Procedures Fulfilling Performance Requirements 


VH Entry Point Name 


Performance Requirement Fulfilled 


1. 


COMPARE MEM 


trricienuy compares two ranges ui 






memory locations 


2. 


FILLMEM 


Efficiently Initializes a range of 






momnru 1 nc A'f i nnc 


3. 


MOVEMEM 


Efficiently moves one range of 






memory locations to another range of 






memory locations 


4. 


SEARCHMEN 


Efficiently searches a range of 






memory locations for a specified 






string of data 



3.4.3.1 Process/Peripheral Requirements 

Following Is a list describing the minimum processor and peripheral requirements for 
successfully executing the ISS: 

1. Processor clock of at minimum 8 MHz. 

2. Capability of addressing a minimum of 1 MB of random access memory (RAM) for software 
development and ISS execution. 

3. A minimum of 40-MB hard disk storage for operating system, program development, and ISS 
applications data storage. 

4. A 1-MB floppy disk drive. 

Note that It would be possible to Implement a more restricted version of the ISS on a system 
providing less process/peripheral capacities than those listed. 

3.4. 3*2 Display Station Requirements 

Following Is a list describing the minimum display-station requirements for successfully 
presenting ISS displays: 

1. Color graphics monitor: An Interactive monitor providing both alphanumeric and graphics 
display capabilities Is necessary. Any mixture of text, graphics, and background colors Is 
allowed. Drawing primitives of at least points, vectors, arcs, circles, and rectangles Is 
required. It Is necessary for the station to clip picture elements so that screen boundaries are 
not exceeded. Color and blink attributes must be assignable to any picture primitive. 

Following are specific monitor requirements: 

a. Screen size of at least 13-inch diagonal. 

b. Dot triad spacing of 0.31 mm or better. 

c. At least 42-Hz, non-interlaced refresh rate to prevent flicker. 

d. Resolution of at least 480 horizontal by 360 vertical. 
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e. Blink capability* 



f. 24 to 32 lines with minimum of 80 character lines. 

g. 480+ characters-per-second writing rate. 

h. At least 10 mlcroseconds-per-plxel vector-writing rate. 

2. Keyboard with function keys and numeric pad. 

3. 96 standard ASCII characters plus varying character sizes. 

4. If not provided, expandable to support light pen, touch panel, mouse, or other pointing 
device. 

3.4.4 VAX-1 1/760 And PH200 Implementations 

In order to determine the portability of the ISS, software Initially Implemented on the 
VAX-11/780 has been Implemented on the 68000-based FM200 microcomputer. In general, key ISS 
modules ported nicely to the PM200 due to (a) the fulfillment, by the PM200, of the Ada 
programming language requirements, host operating system requirements (UNIX), and hardware 
requirements discussed in Sections 3.4.1, 3.4.2, and 3.4.3 and (b) the ease with which the VML 
was relmplemented on the PM200, 

The VML consists of approximately 2500 lines of FORTRAN code and 600 lines of Assembly 
language code on the VAX-11/780. On the PM200, the VML Is approximately 1300 lines of code 
Implemented In the C language. By relirplementlng this relatively small amount of software to 
Interface to the UNIX operating system and oy recompiling tne Ada source on the PM200, programs 
were ported with relative ease. 

It should be emphasized that the PM200 Implementation was to demonstrate the feasibility of 
ISS transportability and the execution of the ISS on a microcomputer. Performance and Winchester 
disk size issues need to be addressed before the PM200 can be considered • a production 
implementation (Section 5.0, Conclusions and Recommendations). 

The problems encountered In porting the software were relatively minor. Differences in the 
command languages for VAX VMS and UNIX had to be reconciled In order to submit programs and print 
jobs. An open file limit (17) exists In UNIX that does not exist In VMS, and this caused minor 
modifications to some application programs. And, several compiler bugs were encountered In the 
Add compiler on the PM200 (to be expected for early Implementations of Ada), causing minor 
modifications In some of the application programs. 



4.0 ISS POTENTIAL 



As a result of the Standardized Software project, significant potential uses exist for the 
ISS; (a) organizations currently using or planning to purchase hardware upon which the ISS now 
operates can use the system Immediately; (b) organizations currently using or planning to 
purchase a system upon which the ISS can operate will be able to use the ISS after Implementation 
of the Virtual Machine Layer for that system; (c) depending on the training requirements for an 
organization, the ISS can be delivered, 1n any combination, as an authoring system, a CAI 
delivery system, and a CMI system; (d) depending on the training requirements for an 
organization, the ISS car be tailored to fulfill those requirements; and (e) ISS users can 
reasonably utilize lower-cost microcomputers, such as the system used 1n the Standardized 
Software project, to perform as a central processor. The following sections elaborate on these 
potential uses. 
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4.1 Current Implementations 



During the project, the ISS was Implemented on two systems: the VAX-1 1/780, using the VMS 
operating system, and the PM200, using the UNIX operating system. There Is significant potential 
associated with each Implementation. 

The VMS Implementation Is significant In that It Is available on an ever-broadening and 
popular series of machines, Including the VAX-11/725, VAX-11/730, VAX-11/750, VAX-11/780, and the 
Micro VAX. DOD organizations currently using or planning to purchase machines from the VAX/ VMS 
line can use the ISS as their training system. 

The UNIX operating system also continues to gain In popularity. Unlike VMS In the VAX I1,e, 
It Is Implemented on mar\y machines, thereby providing an excellent opportunity for transportation 
of the ISS technology. 

For either Implementation, configuration parameters such as central memory size, disk storage 
space, tape storage space, and terminal type should be carefully considered to best operate the 
ISS In a particular training environment. 



4.2 Future Implementations 

In addition to systems utilizing VMS and UNIX, the ISS Is Imp lemen table on other systems that 
fulfill the language, operating system, and hardware requirements specified In Sections 3.4.1, 
3.4.2, and 3.4.3. The capabilities of a potential system should be examined carefully to 
determine the feasibility of ISS Implementation. For a system fulfilling the requirements, the 
Virtual Machine Layer must be Implemented In order for the ISS to operate successfully on that 
system. 



4.3 The Configurable ISS 

Depending on the training requirements for an organization, the ISS can be delivered, In ar\y 
combination, as a CAI authoring system, a CAI delivery system, and a CMI system. If a training 
environment requires CAI that has not been developed, a method to systematically and efficiently 
create courseware Is necessary. The software modules comprising the CAI authoring system (CAI 
Authoring, Graphics, and Simulation Authoring) provide this method. If CAI presentation Is 
required, software modules comprising the CAI delivery system should be used (CAI Presentation 
and Simulation Presentation). And If management and scheduling of assignments, testing, 
remediation, and enrichment activities are necessary, support Is provided via the CMI system (CMI 
Development, CMI Operation, and Data Analysis). 



4.4 ISS Tailoring 

Particular training environments may require hardware devices, terminal types, and/or 
functional capabilities that are not currently provided In the ISS. With the layered and modular 
design of the system (Figure 4), new software and device types can be Integrated Irto the ISS 
with minimal effort. The ISS software Is adaptable In nature, with clean Interfaces provided by 
the Ada package specifications. A terminal definition file can be updated to reflect the 
characteristics of hardware devices to be added to the system. 
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4.5 The ISS Micro As a Central Processor 



By Implementing the software on the PM200 microcomputer, It has been shown that the ISS can 
operate on a more economically feasible machine than minicomputers and mainframes. If, as a 
hypothetical case, a training organization wanted to support 10 students utilizing 10 curricula, 
10 courses, and 10 two-hour CAI lessons, approximately 4 MB of disk storage for Instructional 
data would be required. 



The breakdown of the storage requirements Is as follows: 



1.0 MBytes Storage for 10 curricula 

0.3 MBytes Storage for 10 courses 

0.2 MBytes Storage for 10 active students 

2.5 MBytes Storage for 10 two-hour lessons 

4.0 MBytes Total storage for Instructional data 

Also to be considered are ISS program executables which require approximately 15 MB and 
operating system storage which Is approximately 10 MB. The total ISS Winchester storage 
requirement for this hypothetical case Is, therefore, 29 MB. Winchester disk technology Is 
available to easily accommodate this capacity. Additional Winchester space would allow an 
Increase to even more curricula, courses, and student capacity. Current microcomputer technology 
also allows large amounts of main memory. 



With these capabilities currently available In the PM20O and in microcomputer technology In 
general, a low-cost alternative exists (as compared to minicomputers and mainframes) for certain 
training applications. Figure 6 depicts an example of the levels of capability from which a 
training organization could choose, depending on available funds, storage requirements, and 
computing power necessary. CMI could be performed at the central computer In all cases, and 
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Figure 6. Example of Cost/Performance Alternatives. 
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depending on the Intelligence of the display station, CAI could be performed either under control 
of the central computer or the display statlo.i processor 



5.0 CONCLUSIONS AND RECOMMENDATIONS 

The major goals set forth at the beginning of the Standardized Software project have beer 

Accomplished. Applications software that best satisfies the Functional Description has been 

converted or developed, ihe developed system Is portable. Finally, the system has been 
Implemented on a low-cost minicomputer and microcomputer. 

A follow-on operational test 1$ recownended for both the VAX and PM200 Implementations. 
During this operational test, significant performance upgrades should be made to the software in 
order to support the required ISS user load. The test would also allow a user community to 
evaluate the functionality of the . Appropriate change requests could be Issued to AFHRL for 
evaluation. Enhancements deemed beneficial could then be made In a timely, orderly, and 
non-disruptive manner. 

The PM200 Implementation was to demonstrate the feasibility of ISS transportability and 
execution of the ISS on a microcomputer. While both capabilities have been demonstrated, 
performance and Winchester disk size Issues need to be addressed before the PM200 can be 
considered a production Implementation. Higher-speed, larger-capacity Winchester drives are now 
available and can be placed In existing slots In the PM200. These are recommended as 
replacements for the smaller, slower drives used aurlng the Standardized Software project. 

Upgrade of the PM200 UNIX system Is also recommended to provide more portability. 

Finally, consideration should be given to development of a generic data converter In order to 
transport ISS courseware. With the differences In data packing formats of the m*ny Ada compilers 
that are and will come Into existence, It will be necessary to easily convert those different 
formats. By developing a generic data converter, courseware portability (as well as software 
portability) becomes more feasible. 
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